\subsection{Primera parte: port scanning}

Puede ser importante conocer que puertos están abiertos en un host 
conectado a internet sin tener acceso directo al dicho host. 
Para este fin podemos utilizar el protocolo TCP/IP y, 
simplemente enviando, recibiendo e interpretando los paquetes 
deducir que puertos están abiertos, cerrados o incluso filtrados
por un firewall. La forma más primitiva consiste en utilizar 
la fuerza bruta. Esto es, enviar paquetes a todos los puertos, 
desde el $0$ al $65535$. Lo que se hace es enviar paquetes TCP
a los puertos y analizar la respuesta.

Existen muchas técnicas de escaneo de puertos. En el presente trabajo
sólo nos vamos a enfocar en dos de los más sencillos y conocidos.

\subsubsection{SYN scan}

Este tipo de escaneo utiliza paquetes TCP. Lo que se busca es detectar
el estado del puerto mediante los beneficios del \textit{Three-Way Handshake}.
El escáner envía un paquete TCP del tipo SYN, para lo cual el destino
debiese responder con un paquete SYN-ACK. Luego el escáner cierra
la conexión con un paquete RST. Dado que no se completa el \textit{3-Way},
a este tipo de escáner también se le dice que es del tipo 
\aquote{half-open scanning} porque nunca termina de establecer la conexión.

Después de enviar el paquete SYN, si llega una respuesta, 
la misma puede indicar que hay un servicio escuchando 
(\textit{Open Port}), paquete SYN-ACK
o que la conexión es denegada para ese pedido (\textit{Close Port}), paquete RST.
Si no llega ninguna respuesta, se lo indica como \textit{Filtered Port}.
En este último caso no se puede deducir si el puerto está abierto o cerrado,
pero sí se puede asumir que existe un servicio que está limitando
el ingreso de paquetes, probablemente un Firewall.

Nuestra implementación arma un paquete TCP/IP con los flags TCP en 2, 
o sea SYN, y usando la opción que provee scapy de mandar varios 
paquetes al mismo tiempo, enviamos de a $1000$ paquetes para distintos 
puertos. De esta manera aceleramos el tiempo de escaneo. 
El resultado devuelto son dos conjuntos de puertos: 
abiertos y filtrados. Los que no figuran ni en uno ni en el otro 
se los considera cerrados.

Las ventajas de este método son que no se completa la conexión,
con lo cual es más liviano, ya que se mandan menos paquetes. Además,
es más discreto ya que el host no tendrá logs de los escaneos.

Las desventajas son que requiere permisos de administrador 
del sistema (root), ya que los paquetes que envía se arman a bajo nivel 
y por lo general el Sistema Operativo no ofrece APIs para estas cosas.
Además muchos hosts filtran este tipo de escaneos cuando detectan 
muchos paquetes SYN que llegan en un período corto de tiempo.

El algoritmo envía un paquete por puerto, con lo cual su complejidad 
algorítmica -tomando la cantidad de puertos como entrada- es $O(\#puertos)$.

\subsubsection{Connect scan}

Este tipo de escaneo suele ser considerado el más sencillo pues usa
primitivas que el sistema operativo brinda para funciones de red.
Lo que sucede es que el sistema operativo intenta establecer
un \textit{Three-Way Handshake} vía TCP. Si lo logra, cierra la conexión
para liberar los recursos del destino y así evitar un posible ataque
de denegación de servicios involuntario. Si no logra establecer el
\textit{3-Way} (o sea que el destino respondió negativamente o 
se llegó a un timeout de conexión), se considera que el 
puerto está cerrado.

Las ventajas que presenta es que no es necesario contar con permisos
especiales para ejecutar el escaneo, ya que las funciones 
necesarias son provistas por el Sistema Operativo. 
Pero tiene una desventaja muy importante, dado que es muy conocido
y muy ruidoso, es fácilmente detectable. Este escáner completa el 
\textit{3-Way} y luego cierra, con lo cual, el destino puede fácilmente
guardar los datos del atacante en sus logs.
Además es más pesado que SYN scan ya que envía tres veces más paquetes.

La implementación recorre todos los puertos, la complejidad algorítmica 
de este método es $O(\#puertos)$ siendo asintóticamente la misma,
pero en la práctica más lento y más pesado para la red.

\subsubsection{Experimentos}

Para analizar la performance de ambos escaners y los puertos abiertos
decidimos escanear dependencias Nacionales. Se llevaron a cabo ambos métodos
sobre los siguientes NameServers:
\begin{center}
  \begin{tabular}{l l r}
    Dependencia & NameServer & IP \\
    \hline
    Presidencia de la Nación & presidencia.gov.ar & 200.1.116.83 \\
    Jefatura de Gabinete de Ministros & jgm.gov.ar & 200.47.118.83 \\
    Min. de Cultura y Educación & fausto.mcye.gov.ar & 168.83.90.10 \\
    Min. de Defensa & mindef.gov.ar & 200.41.230.245 \\
    Min. de Desarrollo Social y Medio Ambiente & desarrollosocial.gov.ar & 200.51.45.147 \\
    Min. de Economía y Obras & relay1.mecon.gov.ar & 168.101.16.10 \\
    Min. de Justicia y Derechos Humanos & ns1.jus.gov.ar & 200.1.63.20 \\
    Min. del Interior & mininterior.gov.ar & 200.70.32.17 \\
    Min. de Planificación Federal & ns1.minplan.gov.ar & 200.63.171.171 \\
    Min. de Relaciones Exteriores & mrecic.gov.ar & 200.16.110.58 \\
    Min. de Salud y Acción Social & msal.gov.ar & 200.5.235.214 \\
    Min. de Trabajo y Seguridad Social & trabajo.gov.ar & 200.1.113.132 \\
  \end{tabular}
\end{center}

Se realizaron mediciones de tiempo sobre cada Host mediante SYN Scan y Connect Scan.
Para analizar puertos abiertos sólo se utilizó SYN Scan.

Pudimos constatar que prácticamente los host no tienen puertos abiertos.
Un detalle es que los host analizados no son necesariamente servidores web,
para ello se hubiese tenido que analizar los subdominios \texttt{www} de cada
NameServer. Los resultados del escaneo de puertos abiertos y mediciones
de tiempos dio como resultado:

\begin{center}
  \begin{tabular}{l c r r}
    NameServer & Open Ports & SYN scan (seg) & Connect scan (seg) \\
    \hline
    presidencia.gov.ar      & -       & 616.9197  & 152.95336 \\
    jgm.gov.ar              & -       & 661.6246  & 674.13633 \\
    fausto.mcye.gov.ar      & 540, 873 & 1339.7502 & 1268.41516 \\
    mindef.gov.ar           & 80      & 603.8608  & 93.04899 \\
    desarrollosocial.gov.ar & -       & 630.6926  & 93.29535 \\
    relay1.mecon.gov.ar     & -       & 616.9329  & 93.35894 \\
    ns1.jus.gov.ar          & -       & 609.2985  & 93.31425 \\
    mininterior.gov.ar      & -       & 602.7582  & 119.48078 \\
    ns1.minplan.gov.ar      & 53      & 652.9676  & 101.13741 \\
    mrecic.gov.ar           & -       & 614.1995  & 94.27426 \\
    msal.gov.ar             & -       & 609.6218  & 93.36916 \\
    trabajo.gov.ar          & -       & 615.2018  & 93.45266 \\
    \hline
    \multicolumn{2}{c}{Promedio} & 681.1524 & 247.5197 \\
  \end{tabular}
\end{center}

El siguiente gráfico expone con mayor claridad la comparativa de tiempos.

\begin{figure}[H]
   \begin{center}
   \includegraphics[width=0.9\textwidth]{img/scan_times.png}
   \caption{\textbf{Comparativa tiempos: SYN vs Connect}}
   \label{fig:scan-times}
   \end{center}
\end{figure}

Si bien mencionamos que \textit{Connect scan} es más pesado que \textit{SYN scan}, puesto
que envía tres veces más paquetes, en la práctica obtuvimos resultados
opuestos a este principio. Esto probablemente se deba al tipo de implementaciones
de cada uno. Connect scan trabaja con primitivas del Sistema Operativo, con
lo cual cuenta con muchas optimizaciones que la implementación de Scapy
de alto nivel no maneja. Creemos que allí radica la contrariedad
entre la exposición teórica y los datos empíricos.

\subsection{Segunda parte: detección de versión}

Una técnica utilizada para conseguir información sobre las aplicaciones
corriendo sobre los puertos abiertos se llama \textit{banner grabbing}.
Consiste en realizar pedidos ya sean \aquote{válidos} o \aquote{inválidos} a los protocolos 
correspondientes y analizar la respuesta obtenida. Se busca obtener
el nombre de las aplicaciones y sus respectivas versiones
corriendo sobre ese puerto. Un posible uso es por parte de los 
administradores para generar un inventario de sus aplicaciones.
Pero también puede ser usado para explotar vulnerabilidades conocidas
de una versión de una aplicación. Lo más común es utilizar esta técnica
sobre los protocolos HTTP (80), FTP (21) y SMTP (25)
dado que muchos responden con información de sus servicios.

No siempre se debe hacer una petición errónea para obtener información.
Podríamos hacer una petición HTTP sobre un path válido y aún así
obtener información de los servicios. Por ejemplo,
\begin{verbatim}
$ nc dc.uba.ar 80
  HEAD / HTTP/1.1
  Host: dc.uba.ar

  HTTP/1.1 200 OK
  Server: Zope/(2.13.15, python 2.7.3, linux2) ZServer/1.1
  Last-Modified: Mon, 26 Nov 2012 01:53:58 GMT
  Via: 1.1 www.dc.uba.ar
  Vary: Accept-Encoding
\end{verbatim}
devuelve un request exitoso y además brinda alguna información del 
servidor y de los módulos que usa.

Al hacer un request inválido podríamos obtener más información:
\begin{verbatim}
$ nc dc.uba.ar 80
  test

  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
  <html><head>
  <title>302 Found</title>
  </head><body>
  <h1>Found</h1>
  <p>The document has moved <a href="http://www-2.dc.uba.ar/bug/">here
  </a>.</p>
  <hr>
  <address>Apache/2.2.16 (Debian) Server at bug.dc.uba.ar Port 80
  </address>
  </body></html>
\end{verbatim}

La dificultad del método radica en que cada protocolo tiene sus
reglas de intercambio de mensajes y respuestas. Esto hace que no sólo
se deban generar subtécnicas para cada protocolo sino además se
requiere de una revisión manual de los resultados y tratar de 
corresponder los banners generados con los programas conocidos.

En nuestra implementación de \textit{banner grabbing} pusimos el foco
en los puertos HTTP y SSH. Para HTTP pretendemos buscar dos
servicios web: Apache e Internet Information Services, dado 
que son los dos servicios predominantes. Con respecto a SSH
lo que buscamos es ver si se está corriendo alguna version de OpenSSH.

\subsubsection{Experimentos}

Detectamos hosts corriendo servidores de cada aplicación conocida
por nuestra implementación de banner grabbing, el script se ejecuta
con la opción \texttt{G} para activar el port grabber.

Al ejecutarlo sobre el host \texttt{www.microsoft.com}
\begin{verbatim}
$ sudo python tp.py microsoft.com G

  Resultados del grabber:
  Parece que no es Apache
  ('Parece que el 22 esta cerrado. Error: ', timeout('timed out',))
  Microsoft Windows, IIS: Server: Microsoft-HTTPAPI/2.0
\end{verbatim}
se detectó que hay un servidor IIS corriendo.
En este caso no fue posible conocer la versión.

Luego, sobre el host \texttt{www.ogame.org}
\begin{verbatim}
$ sudo python tp.py www.ogame.org G

  Resultados del grabber:
  Parece que no es Apache
  SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
  Parece que no es IIS
\end{verbatim}
se detectó el servicio OpenSSH corriendo en el puerto 22 con
versión 5.9p1. Además, el sistema operativo parece ser Ubuntu.

Finalmente, sobre \texttt{dc.uba.ar}
\begin{verbatim}
$ sudo python tp.py dc.uba.ar G

  Resultados del grabber:
  >Apache/2.2.16 (Debian) Server at bug.dc.uba.ar Port 80<
  ('Parece que el 22 esta cerrado. Error: ', timeout('timed out',))
  Parece que no es IIS
\end{verbatim}
se detectó un servidor Apache 2.2.16 corriendo sobre Debian en el puerto 80.

\subsection{Tercera parte: OS fingerprinting vía Nmap}

Probamos ejecutar el modulo \textit{OS detection} de \texttt{nmap}.
Primero contra \texttt{dc.uba.ar}
\begin{verbatim}
$ nmap -O -v dc.uba.ar

  Starting Nmap 6.00 ( http://nmap.org ) at 2012-11-26 18:24 ART
  Initiating Ping Scan at 18:24
  Scanning dc.uba.ar (157.92.27.21) [4 ports]
  Completed Ping Scan at 18:24, 0.02s elapsed (1 total hosts)
  Initiating Parallel DNS resolution of 1 host. at 18:24
  Completed Parallel DNS resolution of 1 host. at 18:24, 0.17s elapsed
  Initiating SYN Stealth Scan at 18:24
  Scanning dc.uba.ar (157.92.27.21) [1000 ports]
  Discovered open port 443/tcp on 157.92.27.21
  Discovered open port 80/tcp on 157.92.27.21
  Completed SYN Stealth Scan at 18:24, 4.57s elapsed (1000 total ports)
  Initiating OS detection (try #1) against dc.uba.ar (157.92.27.21)
  Retrying OS detection (try #2) against dc.uba.ar (157.92.27.21)
  Nmap scan report for dc.uba.ar (157.92.27.21)
  Host is up (0.024s latency).
  Not shown: 998 filtered ports
  PORT    STATE SERVICE
  80/tcp  open  http
  443/tcp open  https
  Warning: OSScan results may be unreliable because we could 
  not find at least 1 open and 1 closed port
  Device type: general purpose|firewall|terminal|WAP
  Running (JUST GUESSING): Linux 2.6.X|2.4.X (92%), IPFire Linux 2.6.X (89%), 
  IGEL Linux 2.6.X (86%) OS CPE: cpe:/o:linux:kernel:2.6 
  cpe:/o:ipfire:linux:2.6 cpe:/o:igel:linux:2.6 cpe:/o:linux:kernel:2.4
  Aggressive OS guesses: Linux 2.6.32 (92%), Linux 2.6.31 (90%), IPFire 
  firewall 2.11 (Linux 2.6) (89%), Linux 2.6.15 - 2.6.26 (88%), 
  Linux 2.6.23 - 2.6.38 (88%), Linux 2.6.32 - 2.6.33 (88%), 
  Linux 2.6.32 - 2.6.35 (88%), Linux 2.6.32 - 2.6.38 (87%), 
  Linux 2.6.35 (Ubuntu) (87%), Linux 2.6.18 (86%)
  No exact OS matches for host (test conditions non-ideal).
  Uptime guess: 9.184 days (since Sat Nov 17 13:59:27 2012)
  TCP Sequence Prediction: Difficulty=262 (Good luck!)
  IP ID Sequence Generation: All zeros

  Read data files from: /usr/bin/../share/nmap
  OS detection performed. Please report any incorrect results 
  at http://nmap.org/submit/ .
  Nmap done: 1 IP address (1 host up) scanned in 9.85 seconds
  Raw packets sent: 2090 (97.072KB) | Rcvd: 19 (1.036KB)
\end{verbatim} 

Para comenzar \texttt{nmap} hace un escaneo de puertos.
Primero parece que hace un SYN scan a varios de los puertos predeterminados.
Luego, al detectar que el puerto 80 se encuentra abierto 
se hacen varios intentos de conexión a este puerto, con la siguiente secuencia:
SYN, SYN-ACK, RST. Al enviar un RST al final nunca termina de establecer la conexión.
Luego \texttt{nmap} hace varios ping, envía 300 bytes de datos (0xC) al puerto 31328 UDP.
Esto último creemos que debe ser alguna prueba que le permite decidir sobre el SO.
Luego empieza a enviar paquetes con diferentes flags TCP, recibe las res\-pues\-tas 
y las procesa para determinar el SO. En este caso con una certeza de $92\%$ 
se determinó que el Sistema Operativo utiliza un kernel \textit{Linux 2.6}.

Luego probamos contra \texttt{www.utn.edu.ar}:
\begin{verbatim}
$  sudo nmap -O -v www.utn.edu.ar

  Starting Nmap 6.00 ( http://nmap.org ) at 2012-11-26 18:26 ART
  Initiating Ping Scan at 18:26
  Scanning www.utn.edu.ar (190.114.221.36) [4 ports]
  Completed Ping Scan at 18:26, 0.03s elapsed (1 total hosts)
  Initiating Parallel DNS resolution of 1 host. at 18:26
  Completed Parallel DNS resolution of 1 host. at 18:26, 0.01s elapsed
  Initiating SYN Stealth Scan at 18:26
  Scanning www.utn.edu.ar (190.114.221.36) [1000 ports]
  Discovered open port 80/tcp on 190.114.221.36
  Discovered open port 21/tcp on 190.114.221.36
  Increasing send delay for 190.114.221.36 from 0 to 5 
  due to 11 out of 14 dropped probes since last increase.
  Increasing send delay for 190.114.221.36 from 5 to 10 
  due to 11 out of 11 dropped probes since last increase.
  SYN Stealth Scan Timing: About 35.90% done; ETC: 18:27 (0:00:55 remaining)
  Increasing send delay for 190.114.221.36 from 10 to 20 
  due to 11 out of 11 dropped probes since last increase.
  Increasing send delay for 190.114.221.36 from 20 to 40 
  due to 11 out of 11 dropped probes since last increase.
  SYN Stealth Scan Timing: About 66.90% done; 
  ETC: 18:27 (0:00:38 remaining)
  Completed SYN Stealth Scan at 18:27, 104.09s elapsed (1000 total ports)
  Initiating OS detection (try #1) against www.utn.edu.ar (190.114.221.36)
  Nmap scan report for www.utn.edu.ar (190.114.221.36)
  Host is up (0.023s latency).
  Not shown: 997 filtered ports
  PORT    STATE  SERVICE
  21/tcp  open   ftp
  80/tcp  open   http
  443/tcp closed https
  Device type: general purpose
  Running: Microsoft Windows 2003
  OS CPE: cpe:/o:microsoft:windows_server_2003::sp2
  OS details: Microsoft Windows Server 2003 SP2
  TCP Sequence Prediction: Difficulty=256 (Good luck!)
  IP ID Sequence Generation: Busy server or unknown class

  Read data files from: /usr/bin/../share/nmap
  OS detection performed. Please report any incorrect 
  results at http://nmap.org/submit/ .
  Nmap done: 1 IP address (1 host up) scanned in 106.81 seconds
  Raw packets sent: 2128 (96.240KB) | Rcvd: 1254 (50.492KB)
\end{verbatim}

En este caso se determinó que el Sistema Operativo es \textit{Microsoft Windows Server 2003 SP2}.
Las pruebas que se realizaron fueron parecidas al caso anterior aunque
notamos algunas diferencias. Por ejemplo, en este caso \texttt{nmap} envió
varios paquetes con ACKs repetidos, y además, como este host
tenía más puertos abiertos, el puerto 21 (FTP) entre otros, le permitió a
\texttt{nmap} detectar mejor el sistema operativo.\\

Captura de actividad mediante Wireshark:\\
Sobre la ejecución de \texttt{nmap -O -v dc.uba.ar}, obtuvimos los siguientes registros:

\begin{figure}[H]
   \begin{center}
   \includegraphics[width=1\textwidth]{img/captura_ws_nmap.png}
   \caption{\textbf{Captura Wireshark del inicio de ejecución nmap -O -v dc.uba.ar}}
   \label{fig:captura Wireshark}
   \end{center}
\end{figure}

A partir de este gráfico identificamos en el registro numero 5 un paquete TCP enviado como SYN, desde la IP de nuestra maquina hasta la IP del servidor destino, luego en los registros 8 y 9 se observa el comportamiento del SYN scanning: [SYN, ACK] y [RST] respectivamente. El escaneo que realiza nmap entonces utiliza SYN scanning, listando todos los puertos del host y su estado.

  
